A portion of the disclosure of this patent document contains material to which a claim of copyright protection is made. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but reserves all other rights whatsoever.
1. Field of the Invention
The present invention relates to the field of graphical programming, and in particular to a system and method for interacting with user interface elements associated with a graphical program, e.g., to set or retrieve various properties of the user interface elements.
2. Description of the Related Art
Traditionally, high level text-based programming languages have been used by programmers in writing applications programs. Many different high level programming languages exist, including BASIC, C, FORTRAN, Pascal, COBOL, ADA, APL, etc. Programs written in these high level languages are translated to the machine language level by translators known as compilers or interpreters. The high level programming languages in this level, as well as the assembly language level, are referred to as text-based programming environments.
Increasingly computers are required to be used and programmed by those who are not highly trained in computer programming techniques. When traditional text-based programming environments are used, the user""s programming skills and ability to interact with the computer system often become a limiting factor in the achievement of optimal utilization of the computer system.
There are numerous subtle complexities which a user must master before he can efficiently program a computer system in a text-based environment. The task of programming a computer system to model or implement a process often is further complicated by the fact that a sequence of mathematical formulas, mathematical steps or other procedures customarily used to conceptually model a process often does not closely correspond to the traditional text-based programming techniques used to program a compuert system to model such a process. In other words, the requirement that a user program in a text-based programming environment places a level of abstraction between the user""s conceptualization of the solution and the implementation of a method that accomplishes this solution in a computer program. Thus, a user often must substantially master different skills in order to both conceptually model a system and then to program a computer to model that system. Since a user often is not fully proficient in techniques for programming a computer system in a text-based environment to implement his model, the efficiency with which the computer system can be utilized to perform such modeling often is reduced.
Examples of fields in which computer systems are employed to model and/or control physical systems are the fields of instrumentation, process control, industrial automation, and simulation. Computer modeling or control of devices such as instruments or industrial automation hardware has become increasingly desirable in view of the increasing complexity and variety of instruments and devices available for use. However, due to the wide variety of possible testing/control situations and environments, and also the wide array of instruments or devices available, it is often necessary for a user to develop a program to control a desired system. As discussed above, computer programs used to control such systems had to be written in conventional text-based programming languages such as, for example, assembly language, C, FORTRAN, BASIC, or Pascal. Traditional users of these systems, however, often were not highly trained in programming techniques and, in addition, traditional text-based programming languages were not sufficiently intuitive to allow users to use these languages without training. Therefore, implementation of such systems frequently required the involvement of a programmer to write software for control and analysis of instrumentation or industrial automation data. Thus, development and maintenance of the software elements in these systems often proved to be difficult.
U.S. Pat. Nos. 4,901,221; 4,914,568; 5,291,587; 5,301,301; and 5,301,336; among others, to Kodosky et al disclose a graphical system and method for modeling a process, i.e., a graphical programming environment which enables a user to easily and intuitively model a process. The graphical programming environment disclosed in Kodosky et al can be considered the highest and most intuitive way in which to interact with a computer. A graphically based programing environment can be represented at a level above text-based high level programming languages such as C, Pascal, etc. The method disclosed in Kodosky et al allows a user to construct a diagram using a block diagram editor, such that the diagram created graphically displays a procedure or method for accomplishing a certain result, such as manipulating one or more input variables to produce one or more output variables. In response to the user constructing a data flow diagram or graphical program using the block diagram editor, data structures are automatically constructed which characterize an execution procedure which corresponds to the displayed procedure. The graphical program may be compiled or interpreted by a computer. Therefore, a user can create a computer program solely by using a graphically based programming environment. This graphically based programming environment may be used for creating virtual instrumentation systems, industrial automation systems, modeling processes, and simulation, as well as for any type of general programming.
Thus, graphical programming has become a powerful tool available to programmers. Graphical programming environments such as the National Instruments LabVIEW product have become very popular. Tools such as LabVIEW have greatly increased the productivity of programmers, and increasing numbers of programmers are using graphical programming environments to develop their software applications. In particular, graphical programming tools are being used for test and measurement, data acquisition, process control, man machine interface (MMI), supervisory control and data acquisition (SCADA) applications, simulation, and machine vision applications, among others. A primary goal of graphical programming, including virtual instrumentation, is to provide the user the maximum amount of flexibility to create his/her own applications and/or define his/her own instrument functionality.
When creating a graphical program, a user may place or manipulate icons in a block diagram using a block diagram editor to create a data flow xe2x80x9cprogram.xe2x80x9d A graphical program for controlling or modeling devices, such as instruments, processes or industrial automation hardware, may be referred to as a virtual instrument (VI). In creating a virtual instrument, a user may create a front panel or user interface panel. The front panel may include various user interface elements or front panel objects, such as controls of indicators, that represent or display the respective input and output that will be used by the graphical program or VI, and may include other icons which represent devices being controlled.
The front panel may be comprised in a single window of user interface elements, or may comprise a plurality of individual windows each having one or more user interface elements, wherein the individual windows may optionally be tiled together. When the controls and indicators are created in the front panel, corresponding icons or terminals may be automatically created in the block diagram by the block diagram editor. Alternatively, the user can place terminal icons in the block diagram which may cause the display of corresponding front panel objects in the front panel, either at edit time or later at run time. As another example, the front panel objects may be embedded in the block diagram.
During creation of the graphical program, the user may select various function nodes or icons that accomplish his desired result and connect the function nodes together. For example, the function nodes may be connected in a data flow or control flow format. The function nodes may be connected between the terminals of the respective controls and indicators. Thus the user may create or assemble a data flow program, referred to as a block diagram, representing the graphical data flow which accomplishes his desired process. The assembled graphical program may then be compiled or interpreted to produce machine language that accomplishes the desired method or process as shown in the block diagram.
A user may input data to a virtual instrument using front panel controls. This input data may propagate through the data flow block diagram or graphical program and appear as changes on the output indicators. In an instrumentation application, the front panel can be analogized to the front panel of an instrument. In an industrial automation application the front panel can be analogized to the MMI (Man Machine Interface) of a device. The user may adjust the controls on the front panel to affect the input and view the output on the respective indicators. Alternatively, the front panel may be used merely to view the input and output, and the input may not be interactively manipulable by the user during program execution.
FIG. 1 illustrates an exemplary front panel or user interface panel. The panel includes various user interface elements for providing input to a graphical program and viewing output from the graphical program such as described above. For example, FIG. 1 illustrates a standard push button, labeled xe2x80x9cOFFxe2x80x9d. Other types of standard user interface elements that may be included on a front panel or user interface panel include text fields, list boxes, selection controls, menu bars, tool bars, etc.
In addition to such standard types of user interface elements, a graphical programming environment may also provide other types of specialized user interface elements, e.g., user interface controls that are directed toward instrumentation or measurement applications. For example, FIG. I illustrates several user interface controls resembling knobs such as are found on hardware instruments. FIG. 2 illustrates additional examples of user interface elements useful for instrumentation applications, e.g., a thermometer control, an LED control, a meter control, a waveform graph control, a tank control, etc.
In addition to user interface controls for providing input to or displaying output from a graphical program, a front panel or user interface panel may also include other types of user interface elements, such as elements for simply affecting the appearance of the graphical user interface, e.g., text labels or graphics images.
During execution of a graphical program, it is often necessary or desirable to dynamically alter a user interface, e.g., to reflect the current state of the program. For example, it may be necessary to change various properties or settings of a user interface element, for example to dim or hide a user interface element that is currently inapplicable, change the size or position of a user interface element, change the data value associated with a user interface element, change the color of a user interface element, e.g., to reflect an error state, etc. In addition to changing user interface properties or settings, it may also be necessary to retrieve various properties of user interface elements.
One approach that has been taken in the prior art to setting and retrieving such user interface element properties is the use of xe2x80x9cattribute nodesxe2x80x9d. An attribute node is a node included in the block diagram portion of a graphical program, wherein the node is associated with a particular user interface element. For example, a user may create an attribute node for a user interface element by selecting the user interface element on the user interface panel and issuing a command to create an attribute node for the element, e.g., by selecting an item from a menu or pop-up menu. The user may then configure the block diagram attribute node to set or retrieve the particular user interface element property of interest. U.S. Pat. No. 5,481,741 discloses the use of attribute nodes in a graphical program.
FIG. 3 illustrates two examples of an attribute node, which normally appears in the graphical program block diagram, and the user interface element it affects, which may also appear in the block diagram or in a separate front panel. The attribute node of FIG. 3 sets a xe2x80x9cDisabledxe2x80x9d property of a user interface element. As shown, when a value of xe2x80x9c1xe2x80x9d is wired to the attribute node, the attribute node has the effect of enabling the associated user interface element when the node is executed. When a value of xe2x80x9c2xe2x80x9d is wired to the attribute node, the attribute node has the effect of disabling or dimming the associated user interface element. FIG. 4 illustrates an exemplary graphical program that uses attribute nodes.
One drawback of using a technique such as attribute nodes to interact with user interface elements is that it may be difficult to separate the user interface portion of a program from other portions of the program. Such techniques, for example, may require a node to be included on a block diagram together with other nodes affecting control or data flow of the program. A separate node may be required for each user interface element the program interacts with. In addition to possibly making the block diagram cluttered and difficult to read, this approach may also make it difficult or impossible to encapsulate the user interface logic for a program in a separate portion of the program, e.g., as a graphical sub-program. Thus, it may be desirable to provide an improved system and method for interacting with user interface elements, which may promote such well-known programming principles as code modularization and code re-use.
The problems outlined above may in large part be solved by providing a system and method for enabling user interface code to be encapsulated in a sub-program of a graphical program. For a particular user interface element that a user desires to interact with (as used herein, xe2x80x9cinteracting withxe2x80x9d a user interface element refers to setting or retrieving a property or value associated with the user interface element) in a graphical program, the user may create a reference to the user interface element. For example, a node referencing the user interface element may be placed on the graphical diagram portion of the graphical program. This node may then be connected to a node referred to as a xe2x80x9cproperty nodexe2x80x9d. The user may configure the property node with information specifying which property or set of properties of the referenced user interface element to set or retrieve. When executed, the property node may utilize the reference provided by the node associated with the user interface element in order to interact with the element.
The node referencing the user interface element may also be connected to a subprogram node, wherein the subprogram node represents a subprogram which may include one or more nodes, such as property nodes. The subprogram is operable to receive the user interface element reference and pass the reference to nodes included in the subprogram, such as property nodes or other subprogram nodes, in order to set or retrieve properties of the user interface element. The subprogram may have an associated user interface panel, and a xe2x80x9creference controlxe2x80x9d for receiving a user interface element reference may be included on the panel.
User interface elements may be classed or typed in any of various ways. Given that certain user interface properties may only apply to particular classes or types of user interface elements, type information for a subprogram may be specified. In various embodiments, type information may be specified at various levels of granularity and in various ways. Compatibility, incompatibility, or type coercion information for a user interface element reference that is connected to a subprogram may be visually indicated.